(レポート) DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜 #denatechcon

はじめに

本ブログは2019年2月6日(水)に開催されたDeNA TECH CONFERENCE 2019のセッション、「DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜」のレポートです。

スピーカーは株式会社DeNAの金子 俊一さん。

レポート

本セッションについて

昨年DeNAはインフラについて大きな決断をした オンプレミスを全てパブリッククラウドに移行することにした

背景

DeNAのシステム基盤の状況 適材適所で採用 2018年の時点ではメインのシステム基盤はオンプレミス メリットは圧倒的に安いコスト 明確な理由がある場合はパブリッククラウドも利用 海外向けにクイックにサービスをリリースしたい マネジメントサービスを使いたい 2013年より少し前にパブリッククラウドを利用開始 2013年から本格的にパブリッククラウドを利用 メインで使っているのはAWSとGCP 現在はオンプレミスとパブリッククラウドの比率は同じくらい プライベートクラウドの活用にも挑戦 オンプレミスの運用ノウハウを活かしつつシステム基盤の柔軟性を確保 運用するにあたり解決が難しい問題が散発 パブリッククラウドと同様に使うためには今後もかなり工数がかかるであろうと想定 トップレベルのシステム品質 数十万リクエスト、ペタバイトクラスのデータ そういったシステムの運用ノウハウを蓄積している 一番重要なのはシステムを安定的に動かし「続ける」こと インフラ起因のエラーは一件も放置しない、必ず解決させる 数千万人が使うシステムであってもサーバをダウンさせたことはない ヘビーなシステムでも短期間で構築出来るだけの実力がある 圧倒的な低コスト 現在保有しているオンプレミスは3000台規模 事業規模からすると圧倒的に少ないと自負 創業から20年立つがベンチャーマインドが強い 1円でも安くするという気持ちが全エンジニアにある 調達価格の圧縮と流動性の確保で実現 サーバスペックを固定してもリソースをフルに活用できるよう調整 KVM、相乗り、マルチインスタンス

DeNAシステム基盤を取り巻く環境

10年前、DeNAのメインの事業はECとモバゲー 現在ではソーシャルライブやヘルスケア、オートモーティブ、スポーツなど多岐に渡る 事業サービス以外も多様化 セキュリティ意識の向上による脆弱性や監査への対応、各種認証の取得コスト コンプライアンスに対する意識の向上 地震を始めとした災害に対する対策意識の向上 システム基盤の多様化 ベアメタル、KVM、プライベートクラウド、複数のパブリッククラウド... 環境が多様化して難易度もどんどん上がっている システム基盤の課題 オンプレミス環境 安価で運用出来ているが老朽化が加速 稼働から6年経つと故障率が急激に上昇 サービスデプロイに対しては自動化を進めているがハードウェア故障にかかる工数が無視出来ないレベル パブリッククラウド環境 トータルのシステムコストが非常に増えてきている オンプレミスと比べてコストコントロールが難しい 事業がレガシー化 事業展開スピードに対応出来るだけの柔軟性がインフラに求められる 環境多様化による工数の逼迫 セキュリティ対応や対策の工数が増加

次期システム基盤の要件

システム基盤の課題の解決 老朽化、レガシー化、システムコスト増加、工数逼迫、を解決したい 既存の要件を満たし続ける システム品質を落とすわけにはいかない システムコストは更に下げたい 事業展開スピードに応え続けなくてはならない 限られた人員と期間の中で要件をクリアしていく必要がある

選択肢

オンプレミスの大規模リプレース 老朽化は一旦解消される 数年後にまたリプレースが必要になる 最新のサーバを購入することでサーバ集約が更に可能 集約によってコストダウンが可能 オンプレミスからオンプレミスへの移行なのでシステム品質は維持出来る サーバセットアップは自動化を進めているのでシステムリプレイスをで短時間で可能 解決できない課題 パブリッククラウドを使わなくてはならないケースは無くならない パブリッククラウドのコスト削減にはつながらない 技術負債が維持されたままになってしまう フル構成でDRを作るとコストが2倍 オンプレミス型プライベートクラウドへの集約 解決できない課題が散発しており、システム品質が維持できない パブリッククラウドへの集約 解決出来る課題が非常に多い デメリットとして、工夫無く使うとコストが非常に上がる オンプレミスからのリプレイスにかかるコストが膨大

結論

パブリッククラウドへの集約が一番要件が満たせる パブリッククラウドの長所を活かしつつ短所を解決させたい パブリッククラウドに対して徹底的にコストコントロールを行う 部分最適ではなく全体最適で対応 DeNAらしく物作りに注力したい パブリッククラウドでできることはDeNAが同じ道をたどる必要はない 3年後にシステム基盤をマルチクラウドで全て移行 きっちり準備してから移行したい 安定稼働とコストコントロールをしっかり行うための準備期間 ラック管理や資産管理、ハードウェアの対応など、エンジニアのモチベーションが上がらない業務から解放 複数のパブリックラウドを利用 全体最適の観点で厳選した複数クラウドを利用 トータルコストの圧縮と障害に対する可用性確保の観点 基本はIaaS システムコストや品質面からIaaSをチョイス IaaSであれば今まで持っているインフラノウハウが流用出来る トータルでメリットがあるのであればPaaSやFaaSも積極的に使っていく

キックオフ

2018年4月に体制変更、今後の進め方についてディスカッション DeNA全体についてシステム基盤のロードマップが無かった ロードマップがないからエンジニアに対してどこで技術力優位性を身につけるのか伝えられない 3年をターゲットにロードマップを検討 インフラ部門のマネージャーメンバーでディスカッション 5名の検討メンバー、週1-2回のミーティング 当日は折衷案が優勢 議論が部分最適になり議論が発散 完全な移行に対してネガティブなイメージ 方向性を示す協力なメッセージが必要 コストコントロールを行えばパブリッククラウドもオンプレミスに近い形で運用出来る、という結論が見えてきた ディスカッション内容を部門メンバーに適宜共有 オンプレミス環境を捨てること→そこで培われたノウハウが失われるのではないか？ そのノウハウは今後のDeNAにとって本当に重要なのか。 許容出来ない、失われるものはない、という結論に至った 詳細に検討開始 部門内で意思統一後、経営層とのコミュニケーション 全員が「もっとサービスを良くしたい」と考えているのに、目線の違いから話が噛み合わない 日頃からコンテキストをすり合わせておくことが重要 全社方針へ転換 経営会議で承認、全社に周知 トップダウンで伝え、全エンジニアが前向きに同じ方向に進ませる エンジニアボード(各事業の技術責任者のコミッティ)に対して相談 パブリッククラウド化による影響の確認を綿密に相談 全社への周知 IT基盤担当から事業担当へリプレイススケジュールを相談

実行

移行プロジェクトスケジュール 2018年は移行準備期間 2019年で大半のシステムをパブリッククラウドに移行 パブリッククラウドの全体設計 ネットワーク オフィスやオンプレミスとパブリッククラウド間は全てプライベート通信 VPC間のフィルタ設定 セキュリティ 認証認可基盤の設計 セキュリティ標準モデルの策定と監査の自動化 アカウント管理 パブリッククラウド上のアセット管理システムの開発 ルールが無いとバラバラになりがちなところにしっかりルール制定 システム基盤のクラウド最適化 コストコントロール施策 コストコントロールを実現してからインフルエンスする 銀の弾丸は存在しない 複数のコストコントロールを実行し、数％を積み上げてコストダウンする

まとめ

DeNAはオンプレミスからマルチクラウドに移行します 3000台規模のオンプレミス環境をパブリッククラウドへ 部分最適ではなく全体最適で思考 選択と集中、やることとやらないことを明確にする 必要なことにリソースを集中して投下 パブリッククラウドのメリットを受領しつつ短所を解決させる

さいごに

すごくチャレンジングな取り組みをお聞きすることが出来ました！